A Virtual Private Network (VPN) is a cost effective and secure way of extending enterprise network resources over a shared public data network. Most popular uses of VPNs are to interconnect multiple geographically dispersed sites of an enterprise (known as intranet/extranet VPN) and to provide remote users access to the enterprise resources (known as remote access VPN). In particular, a virtual private network (VPN) is an overlay network that uses the public network to carry data traffic between corporate sites and users, maintaining privacy through the use of tunneling protocols and security procedures.
In the network-based VPN model, an intranet/extranet VPN is created by interconnecting Customer Premise Equipments (CPE) of the enterprise to one or more VPN-aware network elements provisioned for the enterprise customer. A remote access VPN is created by tunneling the remote user's connection to a VPN-aware network element provisioned for the enterprise customer that the user belongs to. The VPN-aware network element then tunnels the connection to the appropriate CPE using tunnel concatenation. One such VPN-aware network element is a service switch called the IP Services Gateway (IPSG). An IPSG can be provisioned to serve a number of enterprise VPN customers each with a number of end users.
The basic method of setting up a VPN from a user or a site to secure enterprise resources is to set up a secure data connection between them over the underlying insecure shared network. An IPSG usually sets up two secure tunnels, one from the user/site to the IPSG itself, and the other from the IPSG to the enterprise. The IPSG is also responsible for maintaining separate and independent security associations with both ends, namely the user/site and the enterprise. The data flows end-to-end through the concatenated tunnel via the IPSG. Note that in a network-based VPN model, the network does not simply act as a conduit, but enables the VPN service. Moreover, the IPSG can enable other value-added services from the tunnel concatenation points. Examples include better QoS guarantees for VPN tunnels, service differentiation among users, offloading of Internet traffic from the enterprise intranet, and the like.
The IPSG provisioning process creates virtual instances of routing mechanisms for each of the customers facilitated in the IPSG. In one possible implementation, each instance may be a separate (virtual) router running customer specific routing algorithms. In other implementations, each instance could be distinct customer specific route entries in the partitioned routing table. As such, each routing instance requires a considerable amount of computing resources. Further, since all the instances share the common resources of the IPSG, the number of VPN customers that can be provisioned on an IPSG is limited. There is a similar restriction on the number of tunnels an IPSG can support. Moreover, due to physical resource constraints, configuring an IPSG with increased number of provisions reduces the number of tunnels that can be handled, and vice versa. IPSG provisioning per customer is usually carried out statically because of the complexity of the process and IPSG provisioning is not changed frequently.
At present, remote access VPNs are mostly limited to end users connecting to the enterprise from remote locations using wireline access like dial-up, DSL, and Cable-Modem lines. With the emergence of high-speed wireless data services in 2.5G and 3G wireless technologies, VPN usage from mobile nodes (that is, mobile VPN services) is growing exponentially.
In order to enable mobile data services, a network service provider (NSP) installs wireless access devices at the edge of its network. Radio-to-packet network gateways (i.e., Mobile Access Points (MAPs)) connect the access devices to the data network. To set up a data session, a mobile end user (hereinafter termed a “mobile node” (MN)) must first connect to a MAP, which then routes the session towards the destination CPE through an appropriately provisioned IPSG. A mobile data session originating from a MN to a MAP, and then routed through an IPSG to the enterprise CPE, is the basis of a network-based mobile VPN service. Currently, the IPSG and MAP are collocated in the network, where an IPSG/MAP performs radio to packet network gateway functions to terminate the MN's connection, as well as conducting other IPSG specific functions.
FIG. 1 depicts a high-level block diagram of a prior art mobile IP network 100. In such a scenario the MN is not free to choose an IPSG, rather its data sessions are anchored to the IPSG serving the MN's current roaming region. Note that the VPN service can be initiated only after the MN has started the data session.
The exemplary network 100 comprises a backbone network 102, such as the Internet, a plurality of enterprise networks 1201 through 120r (collectively enterprise networks 120), and a network service provider (NSP) 101. The enterprise networks 120 each include at least one customer premise equipment (CPE) 122 and a plurality of mobile nodes (MN) 1301 through 130m collectively MNs 130). In this example, there are three VPN customers A, B and C, each with a corresponding intranet site 120. Customer A has two CPEs 12211 and 12212, while customers B and C each have one CPE 12221 and 122rk.
The NSP 101 comprises a network service provider access network 104 having a plurality of IPSGs 106, through 106q (collectively IPSGs 106). As shown in FIG. 1, IPSG1 1061 is provisioned for customer A 1201, IPSG2 1062 is provisioned for customers B and C 1202 and 120r (where r illustratively equals 3), IPSG3 1063 is provisioned for all three customers A, B, and C, 1201, 1202, and 1203 and so on. This implies that IPSG1 1061 has a routing instance for customer A, and a security association with CPEA1 12211 and CPEA2 12212. The security association is used to securely tunnel packets between IPSG1 1061 and the CPEs for customer A (that is, they have a pre-established secure tunnel). Similar associations hold for other IPSGs as well. In an instance where an MN 1301 belonging to customer A roams into the region served by IPSG1 1061, the MN successfully initiates a data session with IPSG1 1061. Thereafter, the MN requests a VPN connection to CPEA1 12211. The IPSG1 serves this request by constructing a secure tunnel between the MN 1301 and IPSG1 1061 and concatenating it with the pre-established tunnel illustratively between IPSG1 1061 and CPEA1 12211.
Afterwards, when this MN 1301 roams into the region served by IPSG2 1062, the data session is reestablished with IPSG2 1062. However, when the MN requests for the VPN service, IPSG2 1062 cannot provide such VPN service, since IPSG2 1062 is not provisioned for customer A. That is, IPSG2 1062 is not logically connected to CPEA1 12211 in a secure fashion. Later on, when this MN roams into the region serviced by IPSG3 1063, the data session again is reestablished with IPSG3 1063. When the MN 1301 requests for the VPN service, IPSG3 1063 is able to provide the VPN session, since IPSG3 1063 is provisioned for customer A.
Presently, in one solution termed “uniform-provision”, in addition to IPSG IPSG1 1061, IPSG3 1063, and IPSG5 106q=5, the NSP also provisions IPSG2 1062 and IPSG4 1064 for customer A. The first uniform-provision solution implies that every IPSG 106 in the network is provisioned for all the customers of the NSP. This is required because of the mobile nature of the users, that is, an MN belonging to any customer can roam into the region served by any IPSG 106 and request for service. Therefore, no IPSG 106 can a priori assume that it would serve only a subset of the customers.
For example, suppose the NSP has “N” IPSGs and each can support at most “M” different provisions (recall that the number of VPN customers that can be provisioned per IPSG is limited). The total number of different provisions the NSP 100 can provide is therefore M×N. However, under this solution each IPSG 106 must be provisioned exactly the same way with every VPN customer. In practice, every VPN customer must be provisioned on every IPSG 106, and this limits the total number of supported VPN customers to merely M. Accordingly, this connectivity solution does not scale with the number of subscribed VPN customers. This, however, is not a problem for non-mobile VPN services such as remote access VPNs from home and intranet/extranet VPNs, since the NSP knows a priori, which customers are going to connect to which IPSGs (due to their geographic locations) and can statically provision the IPSGs with only the relevant subset of VPN customers.
A second solution, termed “tunnel-switching”, allows an IPSG to be provisioned for a subset of customers. For example, IPSG2 1062 tunnels the MN's data session to an IPSG that is provisioned for customer A, such as IPSG1 1061. The tunnel-switching solution requires each IPSG 106 to be aware of the provisions made by other IPSGs, detect the identity of the MN, and tunnel switch the session to an appropriate IPSG 106. It is noted that in certain cases, this method results in using more than one tunnel to connect an MN 130 to the appropriately provisioned IPSG 106.
The second tunnel-switching solution provisions each IPSG with a subset of VPN customers, and supports mobility through tunnel switching the MN's data sessions from the IPSG in the MN's roaming area to the appropriately provisioned IPSG. That is, the tunnel-switching solution maintains connectivity by using two or more tunnels to connect an end user to the appropriate IPSG 106.
The tunnel-switching second solution for providing MN-IPSG-CPE connectivity does not scale, since in order to handle more VPN customers, the IPSGs must support more tunnels, which in turn will reduce the number of provisions that can be made per IPSG 106. Moreover, tunnel switching among IPSGs leads to undesirable redirection of connections (commonly known as “dog-legging”) within the NSP's network, which results in an inefficient usage of network links.